そのセッションマネージャー、本当に必要？プライベートサブネットのEC2への通信方法を考えてみる

セッションマネージャーを導入しようと思ったそこの貴方！まずは既存の環境や導入予定の新規環境を見直してみませんか？プライベートサブネットにあるEC2への通信方法を考えながら、それぞれの長所・短所をまとめてみました。どのような通信方法を選ぶかを考える際の参考にして頂ければ幸いです。

#EC2 Systems Manager

#AWS Systems Manager（SSM）

#AWS

Shirota

2020.01.30

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

ブドウ糖てんこ盛りな ラムネ菓子は良いぞ。
長時間の資格試験、集中力が大事な作業、一気に書き上げたいブログ…… ラムネは全てにおいて有用です。

▲ 目が"冴えます"

突然の熱いラムネ推しからこんにちは。今まさにラムネをかじっているAWS事業本部のShirotaです。
ずっと甘味と言えばチョコレート最推しだったのですが、脳に直接甘味が効くと感じられてからはラムネを食べる頻度が増しています。
ただラムネに含まれるブドウ糖の有用性を語ろうと思って検索しようとしたところ、「ラムネ太る」という心を貫くサジェストに出くわしたのでこのお話はこれくらいで切り上げたいと思います。
やりすぎ、ダメ、絶対。

EC2インスタンスに接続して作業したい

さて、今日はEC2インスタンスに接続して作業を行う時の事をお話ししたいと思います。
いきなりですが、皆さんはどのようにEC2インスタンスに接続していますか？
踏み台サーバからSSH接続、直接SSH接続、セッションマネージャーを使って……色々あると思います。
今、EC2インスタンスに接続する際にとても便利な手段といったら、これなのではないかと思います。そう、その名は AWS Systems Manager Session Manager。

AWS Systems Manager Session Managerは良いぞ(条件付き)

セッションマネージャー、使ってますか？私は結構お世話になっています。
今までだと、単発でお客様のEC2環境に入り作業を実施する際にはSSH通信に必要な秘密鍵をもらい、場合によっては通信経路の変更をセキュリティグループで実施する必要がありました。
秘密鍵をもらう手間と、セキュリティに関する設定を変更する可能性があるといった事から「SSH面倒だなぁ」と思われた事がある方は私以外にもいらっしゃるのではないでしょうか。
そんな2018年9月、「AWS Systems Manager Session Manager」がリリースされました。

SSH不要時代がくるか!?AWS Systems Manager セッションマネージャーがリリースされました!

当時のこの記事のシェア具合からも分かるように、これは待望のリリースでした。
事前準備もほとんど要らずにEC2環境に入れるようになった 事は革新的だと思いました。実際に「秘密鍵をもらう」「セキュリティグループを一時的に変更する」といった作業が減って、ストレスフリーになったなぁと感じています。

「良いぞ(条件付き)」について

意味ありげな「(条件付き)」に気付かれましたか？
セッションマネージャーが特に事前準備なく利用できる環境は、条件があります。
参考に、セッションマネージャーを提供しているAWS Systems Manager利用の前提条件を公式ガイドから引用してみました。

1.AWS アカウントを作成して、必要な IAM ロールを設定します。
2.サービスを使用する AWS リージョンで、Systems Manager がサポートされていることを確認します。
3.サポート対象のオペレーティングシステムを実行するサポート対象のマシンタイプを使用していることを確認します。
4.EC2 インスタンスの場合は、IAM インスタンスプロファイルを作成し、マシンにアタッチします。
5.オンプレミスサーバーおよび VM の場合は、ハイブリッド環境の IAM サービスロールを作成します。
6.Systems Manager エンドポイントへの HTTPS (ポート 443) アウトバウンドトラフィックが許可されていることを確認します。
7.(推奨) Systems Manager で使用する VPC エンドポイントを Amazon Virtual Private Cloud に作成します。
8.AWS によって提供されていない AMI から作成されたオンプレミスサーバー、VM、および EC2 インスタンスの場合は、Transport Layer Security（TLS 証明書）をインストールします。
9.オンプレミスサーバーおよび VM の場合は、マネージドインスタンスのアクティベーションプロセスでマシンを Systems Manager に登録します。
10.マネージドインスタンスごとに SSM エージェントをインストールし、インストールされたことを確認します

Systems Manager の前提条件

色々あるのですが、現行でAWSのEC2を利用している場合には「 2,3,4,6,8,10 」の辺りを確認しておく必要がある事が多いです。

ここで、6について注目してみます。
これはネットワークに関する条件なのですが、「パブリックサブネットにEC2が置いてある状況」だとあまり意識しなくて良い項目となっています。
AWSでは特に変更を加えていない限り、アウトバウンドのトラフィックは全開放となっている為です。
では、プライベートサブネットにEC2が置いてある状況 ではどうでしょう。

▲ 各サブネットからの通信について簡単にまとめてみました

公式ガイドには、以下のように記載されています。

パブリックサブネットのインスタンスはアウトバウンドトラフィックを直接インターネットに送信できますが、プライベートサブネットのインスタンスはできません。

パブリックサブネットとプライベートサブネットを持つ VPC (NAT)

基本的に、プライベートサブネットにEC2を置いただけの環境では、アウトバウンド通信ができません。つまり、 このままだとセッションマネージャーが使えません。
EC2接続においてセッションマネージャーは最強……と言い切りたいのですが、プライベートサブネットにあるEC2に対しては前提条件を満たす為の前準備が必要となります。
そこで、今回は「プライベートサブネットにあるEC2に接続する為に取れる方法」を調べ、それぞれの長所/短所についてまとめてみようと思います。

プライベートサブネットにあるEC2に接続する手段

まずは、セッションマネージャーを使う方法を考えてみましょう。

VPCエンドポイントを用意してセッションマネージャーを使う

上記公式ガイドでも推奨されていた方法を用います。

7.(推奨) Systems Manager で使用する VPC エンドポイントを Amazon Virtual Private Cloud に作成します。

この方法を取る場合、以下のような環境になります。

▲ プライベートサブネットから出られるようになりました

詳細な手順については、弊社千葉の以下のブログを参照すると分かりやすいかと思います。

プライベートサブネットに配置したEC2にAWS Systems Manager Session Managerを使ってアクセスする

長所

何より、インターネットに出ることなくセッションマネージャーが使える 点が大きな利点です。
インターネットに出る事なくEC2接続が完了するという事は、セキュリティ的に見て嬉しいです。
パブリックサブネットのEC2でセッションマネージャーを利用する際と準備するものもほぼ変わりません(今回のVPCエンドポイントの用意くらい)。

短所

東京リージョンにおけるVPCエンドポイントのコストと、EC2インスタンス(t2.micro/Amazon Linux 2)のコストを比較してみました。(2020年1月30日現在)

リソース	1時間当たりの料金
VPCエンドポイント	0.014USD
EC2インスタンス(踏み台)	0.0152USD

ほぼほぼ変わらず、寧ろちょっとだけEC2インスタンスの方が高く見えますが、VPCエンドポイントは基本的に 削除するまで課金が発生します。
また、前述した弊社千葉のブログを読んで頂けると分かりますが、SSMを利用する為に必要なVPCエンドポイントは

com.amazonaws.region.ssm
com.amazonaws.region.ec2messages
com.amazonaws.region.ssmmessages
com.amazonaws.region.s3

の4つが最低限でも必要であり、その内追加料金の要らないゲートウェイ型であるS3のVPCエンドポイントを除いた 3つの 0.014USD × 3 の料金が1時間当たりに発生します。
更に、踏み台サーバとするEC2インスタンスであれば、利用しない時間帯は停止しておく事も可能です。(EBS等で課金が発生はしますが、踏み台に使うインスタンスとして最低限の容量で作成していればそれ程金額は発生しない筈です)
そう考えると、この方法を取る場合コストが 大分嵩んでしまう可能性があります 。

NAT Gatewayを用意してセッションマネージャーを使う

前述した、セッションマネージャーの利用前提条件の6を改めて見てみましょう。

6.Systems Manager エンドポイントへの HTTPS (ポート 443) アウトバウンドトラフィックが許可されていることを確認します。

つまり、以下のような環境が考えられます。

▲ 出られる is 正義

長所

プライベートサブネットにEC2インスタンスを置く場合、EC2インスタンスのパッケージのアップデート等を考慮してNAT Gatewayを設置している可能性があります。
既存環境には影響されますが、元々このような環境が整っていた場合は新たに環境に手を加える事なくセッションマネージャーを利用することができます。

短所

図だと上手く書き分けができていないのですが、はじめに紹介したVPCエンドポイントと異なり AWS環境内で通信が完結しません。
NAT Gatewayはそもそもインターネット向けの通信を可能にする為にあるものなので、 セッションマネージャーを利用するためだけにNAT Gatewayを設置する といった事は プライベートサブネットがプロテクトサブネットになる といった環境の変化を含んでしまい本来の要件以上の変更を加えてしまう可能性があります。
また、NAT GatewayもVPCエンドポイント同様削除するまで課金が発生し、しかも 比較するとお高めです。
1時間当たりの料金にして 約4.4倍 お高いです。
NAT Gatewayの料金に関しては、弊社深澤の以下ブログがインパクトを分かりやすく伝えているので参考にどうぞ。

え、そんなに！？意外と知らないAWSでお金がかかるポイント5選！！第二弾

踏み台サーバからSSH接続をする

この際、原点回帰 してみましょう。

▲ よく見たあの光景

長所

既存環境に踏み台サーバがある場合は、やりたい事(EC2インスタンスに接続するが既に達成されているので「VPCエンドポイントを作成してセッションマネージャーを使う」「NATGatewayを作成してセッションマネージャーを使う」必要がありません。
また、新規に踏み台サーバを作成する場合でも前述したようにVPCエンドポイントと異なりEC2インスタンスは停止する事ができる為、 コスト低めにEC2インスタンスに接続する 事を達成できる可能性があります。

短所

踏み台サーバを用意する事で、そのEC2インスタンスへのセキュリティを考慮する必要性が生じます。
また、新規に踏み台サーバを用意する場合は既存環境に手を加える事になります。
既存環境でこの短所が許容できなくなっていたり、新規に踏み台サーバを設置する事が要件的に難しい場合にはセキュリティを重視されていると思われる為、セッションマネージャーへの切り替えを検討される事をオススメします。